VirtualBox: enable ability to import b2d instances #979
Conversation
|
Cool. That was fast! If we're going to do the migration this way, we will need:
I'm not too worried about importing settings that the user has made manually, since that seems to me that it could be a large amount of work for a not so common use case, but I do think we need to parse the b2d config file and convert it into machine terms. If my b2d configuration was set to allow 4096MB RAM and the new machine doesn't have the same amount, that's going to be an annoying surprise. |
|
@nathanleclaire thanks! yeah i need to do a separate guideline -- i think that should be a separate issue / PR -- thoughts? +1 for planning for the deprecation |
|
added the ability to import cpu and memory settings from the b2d vm. PTAL @nathanleclaire |
| return err | ||
| } | ||
|
|
||
| if err := os.Chmod(dst, fi.Mode()); err != nil { |
There was a problem hiding this comment.
What is this solving? I'm not doubting that it's needed, just curious.
There was a problem hiding this comment.
If you copy a key it will not have the correct permissions. When you then try to ssh, it will fail because we shell out to ssh which the file must be 0600. Here I copy the original file permissions to match the existing key perms.
|
Code is looking good, modulo a few nitpicks- I'll give this functionality a whirl soon. |
|
@nathanleclaire updated ptal |
| cli.StringFlag{ | ||
| Name: "virtualbox-import-boot2docker-vm", | ||
| Usage: "The name of a Boot2Docker VM to import", | ||
| Value: "", |
There was a problem hiding this comment.
I keep thinking that maybe we should default this value to boot2docker-vm, since that's by far the most common name and I have a feeling users will run this flag without args expecting it to "just work".
There was a problem hiding this comment.
+1, I'd certainly expect that myself -- I don't know that's it's very common for users to actually name their boot2docker VMs (even though it's supported to do so)
|
So should we clean up the old |
|
I added an issue to write docs for the 0.3.0 milestone. Tried this on the Windows box I have and it worked well. LGTM |
|
@nathanleclaire Yeah I think that would be in the docs. I don't want to remove it automatically -- that seems too destructive (especially if the import fails for some reason). I think a note in the migration doc would suffice. Thoughts? |
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
ehazlett
force-pushed
the
b2d-import-disk
branch
from
c01c4ad to
d881aa8
Compare
|
@nathanleclaire added docs -- this should close #1047. PTAL |
Recommending |
VirtualBox: enable ability to import b2d instances
|
👍 👍 👍 |
This adds support for importing a b2d instance (in this case, just the disk).
Discussion: should we do a full clone of the VM to bring in any changes the user may make to the VM itself? I didn't do that in the current state as this might add things that Machine does not support (i.e. network configuration, etc).
Refs #904